QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940122.txt

Internet Message Format | 1994-11-13 | 30KB

Date: Sat, 18 Jun 94 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #122
To: tcp-group-digest


TCP-Group Digest            Sat, 18 Jun 94       Volume 94 : Issue  122

Today's Topics:
                            NOS & PLIP.COM
         Standard Digital Radio Interface Proposal (19 msgs)
                         subnetting question

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 17 Jun 1994 11:54:22 -0700
From: [e-mail]
Subject: NOS & PLIP.COM
To: [e-mail]

Howdy all -

Is anyone out there sucessfully running PLIP.COM (Crynwr's parallel
port packet driver) with any of the JNOS variants?  I finally soldered
up the parallel port equivalent of a null-modem cable, set the driver
running on both machines, set JNOS108dfd running on both machines,
plugged in the cable, and ...   ^@$@%!  Nothing!

For what it's worth - these are the commands I used to try to
get things running:

On wy6s.ampr.org.:

 I used the command:  plip 0x60 0x7 0x378 00:00:00:33:11:22
 to start plip

 and added :          attach packet 0x60 en0 8 1500
 to autoexec.nos      route add pc.wy6s en0


On pc.wy6s.ampr.org.:

 I used the command:  plip 0x60 0x7 0x378 00:00:00::11:22:33
 to start plip

 and added :          attach packet 0x60 en0 8 1500
 to autoexec.nos      route add wy6s en0

According to PKTCHK and TRACE, the sending PLIP thinks it's sending
packets just fine - but the receive end gets one 'err_in' for each
attempted packet sent...

Has anyone else had better luck?

Thanks & 73    //Brent  [e-mail].
                      [e-mail].

------------------------------

Date: Fri, 17 Jun 1994 14:15:53 +0200 (DST)
From: Gerard J van der Grinten <[e-mail]>
Subject: Standard Digital Radio Interface Proposal
To: [e-mail] (Russell Nelson)

>
>    From: "Louis A. Mamakos" <[e-mail]>
>    Date: Thu, 16 Jun 1994 23:45:33 -0400
>
>    Clever folks could develop a small single board computer to terminate
>    the ethernet in a device, and which contains a simple ROM-based
>    software module to do generic sorts of things.  Hook it (or build it
>    into) things like radios, rotator boxes, etc.
>
> Yes!  Yes!  Yes!  Sixteen bits of digital I/O, and a sixteen bit D/A
> and A/D would be enough for many purposes.  Or maybe a daughter board
> that implements the I/O?
>
> -russ <[e-mail]>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
> Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
> 11 Grant St.      | [phone] (9201 FAX)    | Quakers do it in the light
> Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.
>
Guess you are avoinding the fundamentals... It is the interface to the radio
we all want. (wanna plug on my HH. where i can pumt 2Mb/s into on its 25kc channel)
The family of daughters and son (sun) boards come later....
Regards, Gerard.
--
Gerard J van der Grinten           [e-mail] [44.137.1.1]
Elzenlaan 8                        [e-mail]         (temporary qrl)
3467 TJ Driebruggen                [e-mail] (home)
Netherlands       (+031)-34871606  Home. (+031)-52748435 Qrl.

------------------------------

Date: Fri, 17 Jun 94 14:58:32 +0100
From: [e-mail] (Adrian Godwin)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

> From: [e-mail] (Brian Kantor)
>
> I'd really recommend the use of RS-485 and RS-530 instead of once again
> creating our own unique-to-ham-radio incompatable-with-the-world
> interface.
>
> What we're talking about here is just a radio modem.  It's no different
> from a wireline, optical, or other modem as far as its interface needs;
> we can (and SHOULD) use established standards wherever we can.  The ones
> mentioned above aren't even a bad fit.
> > - Brian

I'd agree, but Jeffrey felt that the standards he'd looked at weren't
suitable. Why was that ? And did you look at enough standards ?

-adrian


> From: "Louis A. Mamakos" <[e-mail]>
>
> If we really wanted to push the state-of-the-art (Ha!), why not define
> the interface as ethernet, which will be plenty fast enough.  Boards
> for PeeCee boxes are less than $100, and you can hang a bunch of
> "things" on an ethernet segment.

That's at a different level though - it's perfectly reasonable where
you've replace the TNC with a gateway / router, but there's a place
for an interface between such a box and the analogue hardware.
Eventually, it would be desirable if this interface vanished inside
the ethernet-radio, but I stil think it's worth defining for now.

There are some areas where the tnc<->modem doesn't cut cleanly, though -
per-packet power control and carrier-sense is one area, and channell
access other than CSMA (e.g. token passing or intelligent hub) is
another. These can be stretched into a system by putting more intelligence
into the radio/modem unit, but it doesn't seem to fit that well.

> You need only define a protocol to run over the net to carry frames of
> stuff between the various devices.  If you were *really* clever, you
> could also transport PCM audio this way too.
>
> Clever folks could develop a small single board computer to terminate
> the ethernet in a device, and which contains a simple ROM-based
> software module to do generic sorts of things.  Hook it (or build it
> into) things like radios, rotator boxes, etc.
>

Another, incompatible protocol ? :-). TCP seems too much software for
this sort of box ..  is UDP feasible, to avoid all the fragmentation stuff ?

Anyhow, someone will point out that the cheapest way to do this is with a
PC and an I/O board. Another monstrous great box/PSU/fan when a eurocard
box was all that was wanted.

-adrian

------------------------------

Date: Fri, 17 Jun 1994 10:10:40 -0400
From: "Louis A. Mamakos" <[e-mail]>
Subject: Standard Digital Radio Interface Proposal
To: Gerard J van der Grinten <[e-mail]>

> Guess you are avoinding the fundamentals... It is the interface to the radio
> we all want. (wanna plug on my HH. where i can pumt 2Mb/s into on its
> 25kc channel)

I thought the original request was for a digital interface between
things like computers and the internal "modem" in a radio.  If this is
the case, then there was some perception that existing industry
standard interconnections like RS232 are somehow limiting.  I just
suggested that if we're to invent something new, invent something
that will be useful for a decade or more.

Louis A. Mamakos, WA3YMH                      [e-mail]
UUNET Technologies, Inc.                      uunet!louie
3110 Fairview Park Drive., Suite 570          Voice: [phone]
Falls Church, Va 22042                        Fax:   [phone]

------------------------------

Date: Fri, 17 Jun 1994 10:04:21 -0400
From: [e-mail]
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

Uh, let's figure out who's doing what.

The original proposal was for a modem-style connector.  It proposed a
specific form factor (mini-15 pin) in order to fit onto small radios.
All of the modulation,D/A, etc., is left to the radio, since it's an
interface to a digital radio.  Swell.

Counterproposal from Brian:  Use a standard modem interface, since they
may already do the job.  Swell.

Unanswered minor issue:  Do standard interfaces (485/530 et al) handle
clocking the way radios will need it?  Will radios be different from
wireline modems (i.e., does DCE radio or DTE provide TxC)?

Counterproposal from Louie:  Put Ethernet in Digital radio.  My comment:
Yeah, right.  Just what a 10 oz. (that's about 280g to the rest of the
world) pocket radio needs, all that protocol.

Suggestion from me:  Everybody first state what you're trying to
accomplish then propose how, not the other way around.  I think the original
was reasonably clear on the former, but only implicitly.  Do we want
a modem-style interface, or an electrically-heavy multiplexed interface
(like Ethernet, ISDN, ST-bus, etc.)?
  fred k1io

------------------------------

Date: Fri, 17 Jun 94 09:21 EDT
From: [e-mail] (Russell Nelson)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

   Cc: [e-mail] (Russell Nelson), [e-mail],
       [e-mail]
   From: "Louis A. Mamakos" <[e-mail]>
   Date: Fri, 17 Jun 1994 10:10:40 -0400


   > Guess you are avoinding the fundamentals... It is the interface
   > to the radio we all want. (wanna plug on my HH. where i can pumt
   > 2Mb/s into on its 25kc channel)

   I thought the original request was for a digital interface between
   things like computers and the internal "modem" in a radio.  If this is
   the case, then there was some perception that existing industry
   standard interconnections like RS232 are somehow limiting.  I just
   suggested that if we're to invent something new, invent something
   that will be useful for a decade or more.

Seriously.  If you have a 10Mbps microwave link, how else to connect
to it than Ethernet?

Besides which, the world *really* needs an ultra-low-cost TCP/IP
device.  The original KA9Q ran on a CP/M machine, so why can't we make
an embedded system that's small and cheap?

-russ <[e-mail]>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | [phone] (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

------------------------------

Date: Fri, 17 Jun 1994 12:04:38 -0400
From: "Brandon S. Allbery" <[e-mail]>
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

In your message of Fri, 17 Jun 1994 10:04:21 EDT, you write:
+---------------
| Counterproposal from Louie:  Put Ethernet in Digital radio.  My comment:
| Yeah, right.  Just what a 10 oz. (that's about 280g to the rest of the
| world) pocket radio needs, all that protocol.
+------------->8

Yup.  For what we seem to be looking for, proposals like Ethernet, ISDN, SCSI,
IEEE-488, etc. seem to be massive overkill.  "Smart radios" might be a
separate idea worth following up, perhaps as an alternative to the proposed IP
TNC (I think that's being discussed on nos-bbs, not here), but they're not the
issue I understood to be in question here.

++Brandon
--
Brandon S. Allbery       [e-mail]         [e-mail]
Friends don't let friends load Windows NT.        Linux iBCS2 emulation

------------------------------

Date: Fri, 17 Jun 1994 10:33:01 -0600
From: [e-mail] (Jeffrey Austen)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

>   From: "Louis A. Mamakos" <[e-mail]>
>   Clever folks could develop a small single board computer to terminate
>   the ethernet in a device, and which contains a simple ROM-based
>   software module to do generic sorts of things.  Hook it (or build it
>   into) things like radios, rotator boxes, etc.
>
>From: russ <[e-mail]>
>Yes!  Yes!  Yes!  Sixteen bits of digital I/O, and a sixteen bit D/A
>and A/D would be enough for many purposes.  Or maybe a daughter board
>that implements the I/O?

I think you're missing the whole point.  The primary goal of this interface
is to help the *end user* with setting up their station: eliminate custom
cables, recalibration anytime something is changed, etc.  A few items have
been added so that most "sophisticated users" (e.g., pacsat, network nodes,
higher speed, etc.) and experimenters will find the interface useful -- but
not all of them; that would be impossible.

Jeff, k9ja

+-+
Jeffrey Austen       |  Tennessee Technological University
[e-mail]   |  Box 5004
[phone]       |  Cookeville Tennessee 38505   U.S.A.

------------------------------

Date: Fri, 17 Jun 94 14:52:47 PDT
From: Jon Albers <[e-mail]>
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

I am just getting into this discussion, but it seems to me that the goal has
gotten a bit muddled.  YES! We DO NEED a cheap and simple (dirty?) TCP/IP engine.
There was an attempt to get KA9Q into a ROM and put onto a TNC which had some
success.  The newer TNCs (Like the Kantronics KPC-3) seem to have quite a bit
more power than the origional TNC-2s did.

But, that is a different project than a "SDRI"??  Isn't the goal here to simplify
the development and use of modem and TNC hardware??
-------------------------------------
Name: Jon Albers ( [e-mail])
Internal Revenue Service, Headquarters Information and Communications Services
(HQ:I:I),810 7th St., NW, 2nd Floor
Washington, DC 20001

------------------------------

Date: Fri, 17 Jun 94 14:19 EDT
From: [e-mail] (Russell Nelson)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

   Date: Fri, 17 Jun 1994 10:33:01 -0600
   From: [e-mail] (Jeffrey Austen)

   >   From: "Louis A. Mamakos" <[e-mail]>
   >   Clever folks could develop a small single board computer to terminate
   >   the ethernet in a device, and which contains a simple ROM-based
   >   software module to do generic sorts of things.  Hook it (or build it
   >   into) things like radios, rotator boxes, etc.
   >
   >From: russ <[e-mail]>
   >Yes!  Yes!  Yes!  Sixteen bits of digital I/O, and a sixteen bit D/A
   >and A/D would be enough for many purposes.  Or maybe a daughter board
   >that implements the I/O?

   I think you're missing the whole point.

Probably.  Sorry about that.  I just get excited whenever anyone
proposes a small embedded system that is only designed to do one or
two things and can talk TCP/IP.

-russ <[e-mail]>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | [phone] (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

------------------------------

Date: Fri, 17 Jun 1994 16:57:13 -0400
From: "Louis A. Mamakos" <[e-mail]>
Subject: Standard Digital Radio Interface Proposal
To: "Brandon S. Allbery" <[e-mail]>

> Yup.  For what we seem to be looking for, proposals like Ethernet,
> ISDN, SCSI, IEEE-488, etc. seem to be massive overkill.  "Smart
> radios" might be a separate idea worth following up, perhaps as an
> alternative to the proposed IP TNC (I think that's being discussed
> on nos-bbs, not here), but they're not the issue I understood to be
> in question here.

So we're not trying to do something new; fine.  So what's wrong with
RS232 on a DB9, or are we just arguing over a new type of connector
body?

Louis A. Mamakos, WA3YMH                      [e-mail]
UUNET Technologies, Inc.                      uunet!louie
3110 Fairview Park Drive., Suite 570          Voice: [phone]
Falls Church, Va 22042                        Fax:   [phone]

------------------------------

Date: Fri, 17 Jun 1994 16:31:05 -0700 (PDT)
From: [e-mail] (Dennis Rosenauer)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

According to Louis A. Mamakos:
>
> So we're not trying to do something new; fine.  So what's wrong with
> RS232 on a DB9, or are we just arguing over a new type of connector
> body?
>
I agree with this idea.  Why not use the appropriate commercial standard
for the speed we are working at.  If it is low speed use RS-232, for 56K
use V.35 etc. But one your choose a standard, don't "bastardize" it stick
with the signal levels, signal senses and timing contraints.

>From personal experience in working on 56K amateur packet a lot of the test
equipment, such as bit error rate test sets etc., would connect a lot
easier to the modem or router if it had an industry standard interface.
Of course with most industry standards, there are so many standards
to choose from.

I wouldn't get too worried about a given connector but I would really like
to encourage the use of proper levels and timing for a given interface.
Making up a cable with the appropriate connectors at each end is easy, level
and timing translation is much more difficult.

Just my $0.02 worth.

--
Dennis Rosenauer VE7BPE                  [e-mail]
MPR Teltech Ltd.
Wireless Transmission Products           "For every vision there is an
Burnaby, B. C.                            equal and opposite revision"

------------------------------

Date: Fri, 17 Jun 1994 21:09:44 -0500 (CDT)
From: Jeffrey Austen <[e-mail]>
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

We seem to have several thoughts mixed together in this thread.  I find the
idea of an ethernet interface or an IP TNC interesting, but both of these are
quite different than what I am proposing.

Here are my goals:
- the principal audience is the end users and the operators of packet
  "infrastructure" (digipeaters, nodes, links, etc.)
- should be compatible with all current modulation and coding schemes
- should be compatible with most anticipated modulation and coding schemes
- must be easy to use --- plug-n-play is the primary goal --- I and many
  others are tired of this radio-tnc interface hack that we've been using
  for way too long (not that it wasn't a good idea at the time; it's just
  long past the time to come up with something better)
- must be simple enough to be built into future radios (e.g., the next
  generation of mobile radios and even some handhelds)

Here is what I am *not* trying to do:
- replace computers, TNCs, or other boxes
- any form of data processing
- be a technology leader

I have looked at existing serial interface standards, at least the ones I
could find documented in our library (which does not include EIA-530) and a
few others.  The asynchronous interfaces will not work with the PSK satellite
modems nor the GRAPES modems as they are both synchronous.  By performing
clock recovery in the radio we can use a synchronous interface for everything
-- therefore I choose a synchronous interface.  The synchronous interfaces
that I have seen are all too complicated in that they have many signals which
are not needed for this application, have several ways that they can be used,
and use physically large connectors with many pins.  I decided that the best
solution is to use what I can of the standards (electrical signaling levels)
and define the signals needed for this application.

I hope this clarifies my intentions.

Jeff, k9ja
+-+
Jeffrey Austen       |  Tennessee Technological University
[e-mail]   |  Box 5004
[phone]       |  Cookeville Tennessee 38505   U.S.A.

------------------------------

Date: Fri, 17 Jun 1994 22:17:03 -0400 (EDT)
From: DJ Gregor <[e-mail]>
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

Here are a few things that I think should be clarified.

First, I will refer to the "Data Radio" or "DR" as a modem, and the "TNC" as
the communications controller.  This is because the interface is actually
between the modem and the communications controller, not neccisarily between
a TNC and a Data Radio.

> To send data from the TNC to the DR the following items are necessary.
>  - Transmit Data: the data from the TNC to the DR.
>  - Transmit Clock: a clocking signal for the transmit data, originating
>    at the DR.
>  - Request To Send: a signal from the TNC to the DR indicating that
>    data transmission is requested.
>  - Clear To Send: a signal from the DR to the TNC indicating that data
>    transmission may proceed.

[[ stuff deleted ]]

> Much of the delay necessary at the beginning of the transmission are
> due to internal delays in the transmitter.  This delay is made the
> responsibility of the DR rather than the TNC.  When CTS becomes active,
> data can be sent immediately; after the last bit of data has been sent,
> RTS may become inactive.  Additional delay may be added in the TNC (as
> is done currently).

The data should be valid on the rising edge of the clock.  The clock should be
1X.  This is a simple setup and can be used with the popular Z8530 IC.

Both clocks should be provided by the modem.  This way, the communication
controller can be dumb and just use the clocks from the modem.  The data should
not contain any encoding such as NRZI or manchester.  Let the modem worry about
it--keep this thing plug and play.

When the modem has a data stream and a good clock, the "Receive Data Valid"
should be high.  When the communications controller has data that it is ready
to send, it should raise "Request to Send" line and start sending flags.  The
modem should immediately prepare to transmit.  During this time when the trans-
mitter is keying up, the modem can either send the flags from the communication
controller, or send some other kind of waveform to prepare the receiving stat-
ions for data.  When the "Clear to Send" line is active, the communication con-
troller should send at least one more flag, and then start sending data.  When
it is done sending data, it should send at least one flag, bring down the RTS
line, and keep sending flags.  The modem can keep the transmitter keyed if
needed.  The communications controller should NOT add any of its own 'keyup
delay' because circuitry in the modem (it can even be a 555 timer) should take
care of it.

I do NOT think that it is a good idea to use the RS-232 protocol.  It is most
commonly used today as an asychronous protocol, and we are using synchronous
data.  If we did hack RS-232 into an interface like this, we would have a
number of people trying to plug this into a COM port on their PC.

This is a good interface and I think that it should be TOTALLY plug and play.

I would like to see some information on IC's that can do TTL/RS-422/423 conver-
sions.

-----
DJ Gregor, N8QLB
[e-mail]
"...oh, you use DOS, sorry to hear that..."

------------------------------

Date: Fri, 17 Jun 1994 19:46:17 -0700 (PDT)
From: [e-mail] (Jerome Kaidor)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail] (Adrian Godwin)

Adrian Godwin wrote:
>
> Anyhow, someone will point out that the cheapest way to do this is with a
> PC and an I/O board. Another monstrous great box/PSU/fan when a eurocard
> box was all that was wanted.

**** Doesn't have to be monstrous.  There are tiny PC motherboards out
there.  You don't have to use a hard drive;  the firmware could be burned
into a custom ``bios rom'', a socket for which they all have.  You don't
need a display and keyboard, either.  Just a network interface, and
some I/O.   The network i/f could be laid down on its side, making for
a nice small package.  After all, the ISA bus is slow and conservative;
should be no problem to make it work through a couple inches of ribbon
cable....

                              - Jerry Kaidor, KF6VB


------------------------------

Date: Sat, 18 Jun 1994 02:30:55 -0400
From: "Louis A. Mamakos" <[e-mail]>
Subject: Standard Digital Radio Interface Proposal
To: Jeffrey Austen <[e-mail]>

> - should be compatible with all current modulation and coding schemes
How would the interface be complatible?  This is what sort of confused
me before when I suggested using an ethernet-type interface.

> I have looked at existing serial interface standards, at least the ones I
> could find documented in our library (which does not include EIA-530) and a
> few others.  The asynchronous interfaces will not work with the PSK satellite
> modems nor the GRAPES modems as they are both synchronous.  By performing
> clock recovery in the radio we can use a synchronous interface for everything
> -- therefore I choose a synchronous interface.  The synchronous interfaces
> that I have seen are all too complicated in that they have many signals which
> are not needed for this application, have several ways that they can be used,
> and use physically large connectors with many pins.  I decided that the best
> solution is to use what I can of the standards (electrical signaling levels)
> and define the signals needed for this application.

But, RS232 *is* a synchronous-capable interface.  If you look on a
DB25 connector, there are transmit and recieve clock signals, as well
as CTS and RTS used by half-duplex synchronous modems.  I've run RS232
synchronous well above 56Kbps.

So, what's wrong with RS232?  Synchronous interfaces don't have to be
complicated - all you need is what you use for async RS232 and add a
couple of clock signals.  V.35 is essentially the same sort of signals
as RS232 except that the transmit and recieve data and clock signals
are balanced signals (two pins each) whilst the remaining signals are
essentially the same single-ended RS232 levels.

Louis A. Mamakos,WA3YMH                       [e-mail]
UUNET Technologies, Inc.                      uunet!louie
3110 Fairview Park Drive., Suite 570          Voice: [phone]
Falls Church, Va 22042                        Fax:   [phone]

------------------------------

Date: Sat, 18 Jun 1994 10:40:56 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail] (Adrian Godwin)

> > Clever folks could develop a small single board computer to terminate
> > the ethernet in a device, and which contains a simple ROM-based
> > software module to do generic sorts of things.  Hook it (or build it
> > into) things like radios, rotator boxes, etc.
> >
>
> Another, incompatible protocol ? :-). TCP seems too much software for
> this sort of box ..  is UDP feasible, to avoid all the fragmentation stuff ?

The protocols are already there. Just use SNMP to manage it all. If vendors can
demo an SNMP controlled toaster I think we can cope with radio. SNMP needs only IP
and UDP.

Alan

------------------------------

Date: Sat, 18 Jun 1994 10:38:15 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail] (Russell Nelson)

> Seriously.  If you have a 10Mbps microwave link, how else to connect
> to it than Ethernet?

Well ideally I guess you make the PC interface card look like an NE2000 clone.

> Besides which, the world *really* needs an ultra-low-cost TCP/IP
> device.  The original KA9Q ran on a CP/M machine, so why can't we make
> an embedded system that's small and cheap?
>
I'd second this. With a 68HC11 you've just about got enough power to handle say
38.4K TCP/IP at a very low cost. BPQ on a PC is a TSR node that can do IP stuff
but not ip->ax25 conversion or directly IP services.

Alan

------------------------------

Date: Fri, 17 Jun 94 19:02:00 -0000
From: [e-mail] (Mike Bilow)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

Cc: [e-mail]

 g> Unanswered minor issue:  Do standard interfaces (485/530 et al) handle
 g> clocking the way radios will need it?  Will radios be different from
 g> wireline modems (i.e., does DCE radio or DTE provide TxC)?

If you can find a surviving wireline modem in 10 years, I'll be surprised.

You ought to read that neat new book, "ISDN in Perspective."  I forget the
author's name.  :-)

 g> Counterproposal from Louie:  Put Ethernet in Digital radio.  My comment:
 g> Yeah, right.  Just what a 10 oz. (that's about 280g to the rest of the
 g> world) pocket radio needs, all that protocol.

Look at the bright side: it would already have the BNC connector.

-- Mike

------------------------------

Date: Fri, 17 Jun 94 18:52:00 -0000
From: [e-mail] (Mike Bilow)
Subject: Standard Digital Radio Interface Proposal
To: [e-mail]

Cc: [e-mail]

 BK> I'd really recommend the use of RS-485 and RS-530 instead of once again
 BK> creating our own unique-to-ham-radio incompatable-with-the-world
 BK> interface.

I certainly agree with your objection to creating a new interface.

 BK> What we're talking about here is just a radio modem.  It's no different
 BK> from a wireline, optical, or other modem as far as its interface needs;
 BK> we can (and SHOULD) use established standards wherever we can.  The ones
 BK> mentioned above aren't even a bad fit.

I don't agree that RS-485 and RS-530 are good choices.  The cost of the
cheapest existing hardware which implements them is several times the cost of a
TNC.  I still think Ethernet is the most promising contender, since it is very,
very cheap and well standardized.  After all, we are supposed to be playing
TCP/IP here.

-- Mike

------------------------------

Date: Fri, 17 Jun 94 15:58:00 EDT
From: "Patterson, Gary" <[e-mail]>
Subject: subnetting question
To: [e-mail]

Forgive me, this is not directly related to ham radio, but I know there are
tcp experts here. I am the admin of a Class B Internet address space.  Can
I have an east coast and west coast site that advertise subnets of my Class B
space through two different service providers?  Or, must I only advertise my
Class B network address from one point, and then subnet beneath that point?

TNX and 73
Gary Patterson  AA4UR
[e-mail]



------------------------------

End of TCP-Group Digest V94 #122
******************************